[FEAT] Enable buffered iteration on plans #2566
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
July 29, 2024 15:43
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #2566 +/- ##
=======================================
Coverage ? 64.02%
=======================================
Files ? 951
Lines ? 107920
Branches ? 0
=======================================
Hits ? 69101
Misses ? 38819
Partials ? 0
|
desmondcheongzx
approved these changes
Jul 30, 2024
Co-authored-by: Desmond Cheong <[email protected]>
Co-authored-by: Desmond Cheong <[email protected]>
jaychia
added a commit
that referenced
this pull request
Jul 30, 2024
Together with #2566 , closes #2561 This PR changes the way the PyRunner performs resource accounting. Instead of updating the number of CPUs, GPUs and memory used only when futures are retrieved, we do this just before each task completes. These variables are protected with a lock to allow for concurrent access from across worker threads. Additionally, this PR now tracks the inflight `Futures` across all executions globally in the PyRunner singleton. This is because there will be instances where a single execution might not be able to make forward progress (e.g. there are only 8 CPUs available, and there are 8 other currently-executing partitions). In this case, we need to wait for **some** execution globally to complete before attempting to make forward progress on the current execution. --------- Co-authored-by: Jay Chia <[email protected]@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Helps close part of #2561
This PR enables buffering of result partition tasks, preventing "runaway execution" of executions when run concurrently.
The problem previously was that if we ran two executions in parallel (
e1ande2) on a machine with 8 CPUs:e1could potentially run8tasks and keep them buffered (not releasing the resource request)e2attempts to run the next task, it notices that the task cannot be admitted on the system (due to memory constraints)e2thinks that it is deadlocking because there is a strong assumption in the pyrunner today that if a task cannot be admitted, it merely has to wait for some other tasks in the same execution to finish up.e2doesn't have any tasks currently pending (because it is starved). The pending tasks are all buffered ine1. Thus it thinks that it is deadlocking.Solution
1instead of allowing each execution to run as many tasks as it wantsNoneto indicate that the plan is unable to proceed.Note that there is still potentially a problem here, e.g. running > NUM_CPU number of executions concurrently. That can be solved in a follow-up PR for refactoring the way we do resource accounting.